1. Field of the Invention
This invention relates generally to the field of data processing systems. More particularly, the invention relates to a system and method for testing program code.
2. Description of the Related Art
Traditional client-server systems employ a two-tiered architecture such as that illustrated in FIG. 1a. Applications 102 executed on the client side 100 of the two-tiered architecture are comprised of a monolithic set of program code including a graphical user interface component, presentation logic, business logic and a network interface that enables the client 100 to communicate over a network 103 with one or more servers 101. A database 104 maintained on the server 101 provides non-volatile storage for the data accessed and/or processed by the application 102.
As is known in the art, the “business logic” component of the application represents the core of the application, i.e., the rules governing the underlying business process (or other functionality) provided by the application. The “presentation logic” describes the specific manner in which the results of the business logic are formatted for display on the user interface. The “database” 104 includes data access logic used by the business logic to store and retrieve data.
The limitations of the two-tiered architecture illustrated in FIG. 1a become apparent when employed within a large enterprise. For example, installing and maintaining up-to-date client-side applications on a large number of different clients is a difficult task, even with the aid of automated administration tools. Moreover, a tight coupling of business logic, presentation logic and the user interface logic makes the client-side code very brittle. Changing the client-side user interface of such applications is extremely hard without breaking the business logic, and vice versa. This problem is aggravated by the fact that, in a dynamic enterprise environment, the business logic may be changed frequently in response to changing business rules. Accordingly, the two-tiered architecture is an inefficient solution for enterprise systems.
In response to limitations associated with the two-tiered client-server architecture, a multi-tiered architecture has been developed, as illustrated in FIG. 1b. In the multi-tiered system, the presentation logic 121 and/or business logic 122 are logically separated from the user interface 120 of the application. These layers are moved off of the client 125 to one or more dedicated servers 126 on the network 103. For example, the presentation logic 121 and the business logic 122 may each be maintained on separate servers.
This separation of logic components and the user interface provides a more flexible and scalable architecture compared to that provided by the two-tier model. For example, the separation ensures that all clients 125 share a single implementation of business logic 122. If business rules change, changing the current implementation of business logic 122 to a new version may not require updating any client-side program code. In addition, presentation logic 121 may be provided which generates code for a variety of different user interfaces 120 (e.g., standard browsers such as Internet Explorer® or Netscape Navigator®).
To ensure proper operation, applications are generally tested before they are deployed within an enterprise network. As illustrated in FIG. 1c, in current testing environments, testing of the application occurs at the user interface level 120. In one approach to testing, inputs are supplied to the user interface 120 during execution to establish what the predicted proper outputs should be. User interface elements are typically identified via a technical ID or a textual label associated with the elements and the representation of entered data may be based on, for example, value changes of entry fields. The inputs and outputs are recorded in a test script 108 by a test control program 106. Using the recorded outputs, the test script 108 may then be used to test another instance of the user interface 120 by applying the same inputs to the user interface 120 and comparing the resultant outputs to the previously-recorded outputs.
There are a variety of problems associated with the foregoing approach. First, test scripts based on the user interface will most likely break when the user interface has been changed. Given the fact that user interfaces tend to change very frequently, test scripts based on the user interface must frequently be rewritten. Moreover, applications using client-server technology often have more than one type of user interface type for accessing the presentation/business logic, thereby requiring several testing technologies and several test cases for each user interface. For example, browser-based user interfaces are different for every browser type and every browser version (e.g., Netscape 4, Netscape 6, Internet Explorer 5, Internet Explorer 6, . . . etc). Test scripts that were created using one specific browser type/version may only work with that specific browser type/version. In addition, test scripts that were generated from user interface information are not particularly human readable because they deal with user interface identifiers and other technical user interface elements (e.g., text fields, drop down menu items, . . . etc). Finally, during execution of the test script, the user interface must be executed on the client so that the scripted operations can be replayed. With this restriction it is not possible to create load tests that simulate hundreds of users because this would require hundreds of client applications running at the same time.